Improve constraints of nested conditional types applied to constrained type variables#59886
Improve constraints of nested conditional types applied to constrained type variables#59886Andarist wants to merge 1 commit intomicrosoft:mainfrom
Conversation
| if (checkType.flags & TypeFlags.Any || distributiveConditionalConstraintIdentityStack.length !== 0 && !(inferredExtendsType.flags & TypeFlags.Never) && someType(getPermissiveInstantiation(inferredExtendsType), t => isTypeAssignableTo(t, getPermissiveInstantiation(checkType)))) { | ||
| (extraTypes ??= []).push(instantiateType(getTypeFromTypeNode(root.node.trueType), combinedMapper || mapper)); |
There was a problem hiding this comment.
this is the core of the fix, previously only the first level of nested conditional type (in non tail-recursive scenarios) was including the instantiated true type in its extraTypes (the reasoning behind that is outlined in the comment above and in the #56004 's description)
So now we are including it at all nested levels. In other words - previously the forConstraint was only passed to the direct call of getConditionalTypeInstantiation from getConstraintOfDistributiveConditionalType but now this contextual~ information is used for all nested calls.
I've used a global variable to track this as it's not really feasible today to thread this through instantiateType here.
There was a problem hiding this comment.
Why is it not feasible to thread forConstraint through instantiateType?
There was a problem hiding this comment.
Conditional types could appear just at any deeper level of the instantiated type. It's doable to introduce some kind of InstantiationFlags and pass it down to all called functions etc but it felt more complicated to attempt doing it. It would also be fairly easy to forget to pass that down somewhere.
| function f9<S extends string>( | ||
| x: IsMatchingStringInfiniteRecursionInFalseType2<S>, | ||
| ) { | ||
| let t1: 1 = x; // Error |
There was a problem hiding this comment.
The error here changed from "Type instantiation is excessively deep and possibly infinite" to "Type '1 | 2' is not assignable to type '1'".
It feels fine here but perhaps it's not fine in general case and I should only return neverType for recursive calls when the compiler is instantiating for the true type. This change comes from the fact that I'm letting the neverType to be returned for any recursive call and this one comes from the false type.
|
@typescript-bot test it |
|
Hey @gabritto, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: frida-gum Package: ramda Package: styled-components |
|
@gabritto Here are the results of running the user tests with tsc comparing Everything looks good! |
|
@gabritto Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
@gabritto Here are the results of running the top 400 repos with tsc comparing Something interesting changed - please have a look. Details
|
|
@Andarist seems like a bunch of things broke because some types became |
|
I have a hunch that this might be related to my comment here. I'll investigate and report back with the findings and new tests. |
fixes #59868
this is an extension of #56004